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Beschreibung 

Programmierung von zyklischen Maschinen 

5 Die Erfindung bezieht sich auf ein Verfahren zur Programmie- 
rung von zyklischen Maschinen, insbesondere von Produktions- 
maschinen. 

Es ist heutzutage ublich, sowohl fur die speicherprogrammier- 
10 bare Steuerung (SPS) als auch fur die Bewegungssteuerung (MC) 
jeweils unterschiedliche hierarchische Ablaufebenen zu model- 
lieren, denen Software-Tasks zur Steuerung des jeweiligen 
technischen Prozesses zugeordnet werden. Diese Tasks konnen 
^ Systemauf gaben erfullen, sie konnen aber auch anwenderpro- 

15 grammiert sein. 

Aus DE 197 40 550 Al ist es bekannt, dass Prozesssteuerungs- 
f unktionalitaten der speicherprogrammierbaren Steuerungen 
"SPS" und Bewegungsf unktionalitaten von MC-Steuerungen in ei- 
20 nem einheitlichen konf igurierbaren Steuerungssystem integ- 
riert werden konnen. 

Diese SPS/MC-Integration geschieht in Form des Zusammenschal- 
tens von SPS- und MC-Steuerungsbaugruppen . Bei einer solchen 

25 Ausfuhrung der Integration wird aber keine optimale und effi- 
ziente Taskstruktur fur die Gesamtheit der Steuerungsauf gaben 
erreicht. Aufierdem werden bei dieser Art der Integration 
hauptsachlich die klassischen MC-Funktionalitaten, wie sie 
insbesondere fur Werkzeugmaschinen relevant sind, unter- 

30 stiitzt. Anf orderungen an die Steuerung, wie sie aus dem Be- 
trieb von Produktionsmaschinen bekannt sind, werden durch 
diese Art des Zusammenschaltens von SPS- und MC-Steuerungs- 
baugruppen nicht optimal unterstiitzt . 

35 Aus EP 0 735 445 A2 ist es bekannt, zum Betrieb einer Werk- 
zeugmaschine oder eines Roboters einen gesonderten Wartebe- 
fehl (WAIT) zu gebrauchen. Der hier beschriebene Wartebefehl 
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(WAIT) unterstutzt aber insbesondere die Steuerung von Pro- 
duktionsmaschinen noch nicht optimal. 

In der Anmeldung DE 19 93 19 33.2 wird vorgeschlagen, den 
5 Takt des Kommunikationssys terns zwischen dem PC-System und den 
peripheren Geraten fur einen Wechsel zwischen einem Echtzeit- 
betriebsprogramm und einem Nicht-Echtzeitbetriebsprogramm 
heranzunehmen . Hier ist es aber die Aufgabe dieser Taktab- 
greifung aus dem Kommunikationssystem, in einem industriellen 

10 Prozess einen moglichst reibungslosen Wechsel zwischen Echt- 
zeit- und Nicht-Echt zeitanwendungen stattfinden zu lassen. 
Bei dieser Ausges taltung wird der Grundtakt aber nur aus dem 
Takt des Kommunikationsmediums abgeleitet und er wird nur filr 
den Wechsel des Betriebssys temmodus eines PC-Systems verwen- 

15 det. 

Des weiteren benotigen die heutzutage tiblichen Verfahren fur 
die Programmierung zyklischer Maschinen unterschiedliche Pro- 
gramme, deren Koordinierung uber sog. "Event-Handler" er- 

20 folgt. Die Programmierung zyklischer Maschinen ist damit um- 
standlich und ein "Event-Handler" verursacht Overhead und 
driickt die Performance. Zyklischen Maschinen zeichnen sich im 
eingeschwungenen Zustand durch einen periodisch wiederkehren- 
den Vorgang oder Zyklus aus. Von diesem Zyklus ist direkt die 

25 Produktivitat der Maschine abhangig. Eine Verkurzung bzw. 
Verkleinerung des Zyklus erhoht die Produktivitat und die 
Performance der Maschine. Beispiele ftir zyklische Maschinen 
sind : Verpackungsmaschinen ( z . B . Schlauchbeutelmaschinen, 
Fullmaschinen oder Verschlieflmaschinen) aber auch Pressen 

30 (z.B. Walzenvorschubmaschinen) . Fur die Performance von Ver- 
packungsmaschinen sind z.B. eine schnelle Druckmarkensynchro- 
nisation und eine dazugehorige schnelle Oberlagerung von Kor- 
rekturbewegungen ausschlaggebend. Heutzutage werden solche 
Auf gabenstellungen noch nicht optimal gelost. 

35 

Der Erfindung liegt daher die Aufgabe zugrunde, fur jeweils 
unterschiedliche Steuerungsauf gaben und unterschiedliche 
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Randbedingungen bzw. Anf orderungen des zugrunde liegenden 
technischen Prozesses in einf acher Weise ein konf igurierbares 
Ablauf ebenenmodell fiir die Steuerungs -Tasks einer industriel- 
len Steuerung fur zyklische Maschinen zu erstellen, wobei die 
5 Programmierung des Maschinenablauf in einem sequentiellen 
Programm erfolgen kann. 

Die Er finder gehen dabei von der Annahme aus, dass dies prin- 
zipiell zum einen durch ein einheitliches konf igurierbares 
10 Ablauf ebenenmodell fiir die Steuerungs-Tasks der industriellen 
Steuerung erreicht wird und zum anderen durch Mechanismen 
(Wait_f or_Condition-Bef ehl ) , die es einem Anwender ermogli- 
^ chen, im Programmf luss auf beliebige Bedingungen zu warten 
und hoherprior zu reagieren. 

15 

Von diesem Ansatz ausgehend wird die oben genannte Aufgabe 
durch f olgende auf einander f olgenden Schritte gelost : 

a) Erstellen einer mit einem Runtime-System ausgestatteten 

20 industriellen Steuerung mit priorisierten Ablaufebenen und 

Tasks, wobei mindestens eine sequentielle Ablaufebene er- 
stellt wird, 

b) Formulieren eines Maschinenablauf s in einem sequentiellen 
2 5 Programm und 

c) im sequentiellen Programm durch spezifische Mechanismen 
bereitstellen, dass 

1) das Warten auf das Erfiilltsein von Bedingungen hoch- 
30 prior durchgef uhrt werden kann und 

2) dass nach Erfiilltsein der Bedingung die nachf olgende 
Programmsequenz bis zu einem definierten anwenderpro- 
grammierten Ende hochprior durchgefuhrt werden kann, 



35 



wobei den Ablaufebenen System- und/oder Anwenderprogramme zu- 
geordnet werden. 
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Durch die Priorisierung der Ablaufebenen konnen die Tasks zum 
Betrieb der Steuerung je nach ihrer Wichtigkeit bzw. den An- 
forderungen, die an ihnen gestellt werden (z.B. bzgl. des 
Antwortzeitverhaltens ) auf unterschiedlich prioren Ebenen zum 
5 Ablaufen komiuen. Ein weiterer Vorteil liegt darin, dass der 
Anwender in einem sequentiellem Programm mit einfachen Mecha- 
nismen komplexe Synchronisationsbedingungen (z.B. das Warten 
auf das Eintreffen von Bedingungen) formulieren kann, ohne 
dass weitere Mechanismen wie z.B. Event-Handler erforderlich 

10 sind. Dadurch wird einerseits in der Steuerung Verwaltungs- 
Overhead vermieden und andererseits aus programmiertechni- 
scher Sicht das Lokalitatsprinzip unterstutzt. Durch die Zu- 
ladbarkeit von Programmen in die Ablaufebenen kann der Anwen- 
\ v der die Funktionalitat der Steuerung .sehr flexibel an die 

15 zugrunde liegenden Anf orderungen des technischen Prozesses 
anpassen . 

Der beschriebene Mechanismus und der dazugehorige Befehle 
werden im Ausf iihrungsbeispiel als "wait_f or-condition" be- 
20 zeichnet. 

Eine erste Ausgestaltung der vorliegenden Erfindung liegt 
darin, dass die Ablaufebenen aus Systemebenen und/oder Anwen- 
derebenen erstellt werden. Dadurch hat der Anwender die Mog- 
25 lichkeit sehr flexibel ein Runtime-System fur eine indus- 

trielle Steuerung zu erstellen, das den jeweiligen Anforde- 
rungen und Randbedingungen des technischen Prozesses angemes- 
sen ist. 

30 Eine weitere Ausgestaltung der vorliegenden Erfindung liegt 
darin, dass das Ablauf ebenenmodell getaktet ist, wobei der 
Grundtakt aus einem internen Timer oder aus einem internen 
Takt eines Kommunikationsmediums oder aus einem externen Ge- 
rat oder von einer Grofie , die zum technologischen Prozess 

35 gehort ableitbar ist. Dadurch kann sehr flexibel und sehr 

einfach der Grundtakt fiir das Ablauf ebenenmodell abgeleitet 
werden. Dadurch, dass der Grundtakt fiir das Ablauf ebenenmo- 
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dell auch von einer Grofie, die zum technologischen Prozess 
gehort, ableitbar ist, kann auf eine sehr einfache Weise eine 
direkte Ruckkopplung aus dem technologischen Prozess zur 
Steuerung erhalten werden. 

Ein Ausfiihrungsbeispiel der Erfindung ist in der Zeichnung 
dargestellt und wird im folgenden erlautert. 

Dabei zeigen: 

FIG 1 die wesentlichen Ablaufebenen einer klassischen 



speicherprogrammierbaren Steuerung, 



FIG 2 



die wesentlichen Ablaufebenen einer Bewegungssteue- 



rung, 



FIG 3 



schematische Darstellung einer industriellen Steue- 



rung, 



FIG 4 



das Ablauf ebenenmodell der er f indungsgemaiien indus- 
triellen Steuerung, 



FIG 5 



ein Ausfiihrungsbeispiel fur das Zuladen von Anwen- 
derprogrammen in die Anwenderebenen, 



FIG 6 



ein Ausfiihrungsbeispiel fur den Gebrauch und den 
Mechanismus des Wait_f or_Condition-Bef ehls, im Ab- 
lauf ebenenmodell der erf indungsgemaflen industriel- 
len Steuerung, 



FIG 7 



ein weiteres Ausfiihrungsbeispiel fUr den Gebrauch 
und den Mechanismus des Wait_f or_Condition-Bef ehls, 
im Ablauf ebenenmodell der erf indungsgemaiien indus- 
triellen Steuerung, 



FIG 8 



die syntaktische Beschreibung des 

Wait_for_Condition-Befehls in einem Syntaxdiagramm, 



FIG 9 



ein Beispiel fur die Formulierung einer Expression 
in programmiersprachlicher Notation und 



FIG 10 in einer Schemadarstellung Moglichkeiten, wie der 
Grundtakt fiir die industrielle Steuerung gewonnen 
wird . 

In der Darstellung gemafi FIG 1 sind die wesentlichen Ablauf- 
ebenen einer klassischen speicherprogrammierbaren Steuerung 
(SPS) r angeordnet nach ihrer Prioritat, gezeigt. Der Priori- 
tatsanstieg ist dabei durch einen Pfeil symbolisiert . In der 
niederpriorsten Ebene werden, wie durch eine gestrichelte Li- 
nie angedeutet, zwei unterschiedliche Aufgaben, namlich ein 
freier Zyklus, d.h. "Anwenderebene freier Zyklus" und eine 
Hintergrund-Systemebene, d.h. "Systemebene Hintergrund" abge- 
wickelt. Der Hintergrund-Systemebene sind z.B. Kommunikati- 
onsaufgaben zugeordnet. Bei einer folgenden Anwenderebene, 
bezeichnet als "Anwenderebene zeitgesteuert " , ist der Aufruf- 
takt der Tasks bzw. der Programme dieser Ebene parametrier- 
bar. Es erfolgt eine Oberwachung dahingehend, ob die Bearbei- 
tung eines Anwenderprogrammes dieser getakteten Ebene recht- 
zeitig abgeschlossen ist, bevor das Startereignis erneut auf- 
tritt. Lauft die Taktzeit ab, ohne dass das Anwenderprogramm 
der zugeordneten Ebene fertig abgearbeitet ist, wird eine 
entsprechende Task einer prioritatsmaflig iibernachsten "Anwen- 
derebene fur asynchrone Fehler" gestartet. In dieser "Anwen- 
derebene fur asynchrone Fehler" kann der Anwender die Behand- 
lung von Fehlerzustanden ausprogrammieren . 

Auf die "Anwenderebene zeitgesteuert" folgt eine "Anwender- 
ebene Events". Die Reaktion auf externe oder interne Ereig- 
nisse (Events) erfolgt innerhalb der "Anwenderebene Events". 
Ein typisches Beispiel fur ein solches Ereignis ist das 
Schalten eines binaren bzw. digitalen Eingangs, wodurch typi- 
scherweise ein Ereignis ausgelost wird. In einer "Systemebene 
hochprior" iiegen die Aufgaben des Betriebssystems, welche 
die Arbeitsweise der programmierbaren Steuerung (SPS) sicher- 
stellen . 



Die Darstellung gemafi FIG 2 zeigt die wesentlichen Ablaufebe- 
nen einer Bewegungssteuerung (MC) . Auch hierbei sind die ein- 
zelnen Ebenen nach ihrer Prioritat hierarchisch, wie durch 
einen Pfeil symbolisiert, angeordnet. Eine " Systemebene Hin- 
tergrund" und eine "Anwenderebene sequentiell " haben eine 
gleiche Prioritat, namlich die niedrigste. Diese aufgabenma- 
fiige Zugehorigkeit ist wie bei FIG 1 durch eine gestrichelte 
Linie symbolisiert. Die Tasks der "Anwenderebene sequentiell" 
werden zusainmen mit den Tasks der "Systemebene Hintergrund" 
im Round-Robin-Verfahren abgearbeitet . Typische Tasks der 
"Systemebene Hintergrund" sind z.B. solche fur Kommunika- 
tionsauf gaben. In der "Anwenderebene sequentiell" laufen die 
vom Anwender programmierten Programmteile fur die eigentliche 
Steuerungsaufgabe. Stoflt die Steuerung in einem dieser Pro- 
grammteile auf einen Bewegungs- oder Positionierbef ehl, wird 
ein "Suspend" gesetzt, d.h. das Anwenderprogramm wird" an. die- 
ser Stelle unterbrochen. In diesem Fall wird ein Befehl syn- 
chron genutzt. Die Abarbeitung dieses Bewegungs- oder Positi- 
onierbefehls geschieht in einer hochstprioren "Systemebene 
getaktet". Ein jeder Lageregler oder Interpolator, der in der 
"Systemebene getaktet" ablauft, fuhrt diesen Bewegungs- bzw. 
Positionierbef ehl aus. Nach Ausfiihrung des Befehls wird in 
die "Anwenderebene sequentiell" zuriickgesprungen und das 
durch "Suspend" unterbrochene Anwenderprogramm wird durch ein 
"Resume" an der gleichen Stelle fortgesetzt. Die "Systemebene 
getaktet" enthalt neben den schon erwahnten La:gereglern auch 
den Interpolationsteil der Steuerung. 

Auf die niederpriorste Ebene setzt die "Anwenderebene Events" 
auf. Hier sind solche Tasks untergebracht , die auf externe 
oder interne Ereignisse reagieren. Solche Ereignisse konnen 
beispielsweise Alarme sein. 

In einer folgenden "Anwenderebene synchrongetaktet " laufen 
synchron getaktete Anwender-Tasks ab, z.B. Regler f unktionali- 
taten. Diese Tasks sind synchronisiert zu getakteten System- 



200023222 



8 

funktionen wie zum Beispiel Interpolator, Lageregler oder 
zyklische Buskommunikation . 

In der Darstellung gemafi FIG 3 wird in Form eines Struktur- 
bildes gezeigt, dass die Steuerung eines technischen Prozes- 
5 ses PI liber das Runtime-System RTS einer industriellen Steue- 
rung erfolgt. Die Verbindung zwischen dem Runtime-System RTS 
der Steuerung und dem technischen Prozess PI geschieht bidi- 
rektional liber die Ein-/Ausgange EA. Die Programmierung der 
Steuerung und damit das Festlegen des Verhaltens des Runtime- 

10 Systems RTS geschieht im Engineering-System ES . Das Enginee- 
ring-System ES enthalt Werkzeuge fur die Konf igurierung, Pro- 
jektierung und Programmierung fur Maschinen bzw. fur die 
f Steuerung technischer Prozesse. Die im Engineering-System er- 
stellten Programme werden liber den Inf ormationspf ad I in das 

15 Runtime-System RTS der Steuerung ubertragen. Beztiglich seiner 
Hardware-Ausstattung besteht ein Engineering-System ES tibli- 
cherweise aus einem Computersystem mit Graphikbildschirm 

v . lj • jl j_ ci_y / / Lxny ajjcnxi a_ olui l Lcin \ * n> * laouauui una naui) f 

Prozessor, Arbeits- und Sekundarspeicher , einer Einrichtung 
20 ftir die Aufnahme computerlesbarer Medien (z.B. Disketten, 
CDs) sowie Anschlusseinheiten fur einen Datenaustausch mit 
anderen Systemen (z.B. weiteren Computersystemen, Steuerungen 
fur technische Prozesse) oder Medien (z.B. Internet). Eine 
Steuerung besteht iiblicherweise aus Eingabe- und Ausgabeein- 
25 heiten, sowie aus Prozessor und Programmspeicher • Es ist auch 
k vorstellbar, dass die Steuerung eines technischen Prozesses 
PI uber mehrere Runtime-Systeme RTS von industriellen Steue- 
rungen erfolgt. 

30 Die Darstellung gemaJi FIG 4 zeigt das Ablauf ebenenmodell der 
industriellen Steuerung. Die Priorisierung der Ebenen wird 
durch einen Pfeil in Richtung zur hochsten Prioritat angedeu- 
tet. Die niederpriorsten Ebenen sind die "zyklische Anwender- 
ebene" und die "sequentielle Anwenderebene" . Diese beiden E- 

35 benen laufen mit der gleichen Prioritat. Deshalb sind diese 

Ebenen in der Darstellung gemali FIG 4 durch eine gestrichelte 
Linie getrennt. Die "zyklische Anwenderebene" beinhaltet die 
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"Background Task", die zykluszeituberwacht ist. In der "se- 
quentiellen Anwenderebene" werden die "Motion Tasks" durch- 
laufen. "Motion Tasks" sind nicht zykluszeituberwacht und 
dienen im Wesentlichen zur Beschreibung sequentieller Ablau- 
5 fe. "Motion Tasks" werden quasiparallel abgearbei tet . Gene- 
rell enthalten alle Anwenderebenen eine oder mehrere Tasks. 
Die Tasks nehmen die Anwenderprogramme auf. Die Tasks der 
"zyklische Anwenderebene" und der "sequentiellen Anwenderebe- 
ne" werden in einem gemeinsamen Round-Robin-Zyklus abgearbei- 
10 tet. 

Die nachstf olgende Ebene ist die " zeitgesteuerte Anwenderebe- 
^ ne". Die Tasks dieser Ebene werden zeitgesteuert aktiviert. 

Die Zeitsteuerung ist einer Granularitat von Millisekunden 
15 einstellbar. Auf die "zeitgesteuerte Anwenderebene" folgt die 
"ereignisgesteuerte Anwenderebene". In dieser Ebene werden 
nach Erkennen eines User Interrupts so genannte "User Inter- 
rupt Tasks" aktiviert. User Interrupt Ereignisse konnen als 
logische Verkniipfung von Prozessereignissen und/oder internen 
20 Zustanden formuliert werden. 

Die nachsthohere Ebene ist die "Anwenderebene fiir System Ex- 
ceptions". In dieser "Anwenderebene fiir System 
Exceptions" werden System Interrupts uberwacht, bei deren 
25 Eintreffen so genannte "Exceptions", d.h. Ausnahmef allbehand- 
[ lungen, generiert werden. In der "Anwenderebene fiir System 
Exceptions" gibt es z.B. f olgende Tasks, die bei Auftreten 
eines entsprechenden System Interrupts aktiviert werden: 

30 a) "Time Fault Task", die beim Ansprechen von ZeitiAberwachun- 
gen aktiviert wird, 

b) "Peripheral Fault Task", die z.B. bei Prozess- und Diagno- 
sealarmen aktiviert wird, aber auch bei Stationsausf all o- 
35 der Stationswiederkehr , 
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c) "System Fault Task", die bei allgemeinen Systemf ehlern ak- 
tiviert wird, 

d) "Program Fault Task", die bei Programmierf ehlern (z.B. Di- 
vision durch Null) aktiviert wird, 

e) "Time Fault Background Task", die beim Ansprechen der Zyk- 
luszeituberwachung der Background Task aktiviert wird und 

f) "Technological Fault Task", die bei Technologief ehlern ak- 
tiviert wird. 

Als nachstes folgt die Ebenengruppe "synchron getaktete Ebe- 
nen" . Diese Ebenengruppe besitzt die hochste Prioritat im Ab- 
lauf ebenenmodell . Die einzelnen Ebenen dieser Ebenengruppe 
konnen untereinander weitere Priorisierungen aufweisen. Die 
Ebenengruppe "synchron getaktete Ebenen" besteht aus mindes- 
tens einer Systemebene und mindestens einer Anwenderebene. 
Die Systemebenen beinhalten die Systemf unktionen wie z.B. La- 
geregler oder Interpolator. In die Anwenderebenen dieser Ebe- 
nengruppe konnen von einem Anwender flexibel Anwenderprogram- 
me (API - AP4; FIG 5) zugeladen werden. 

Fur die Taktung der "synchron getakteten Ebenen" gibt es eine 
Reihe unterschiedlicher Taktgenerierungsmoglichkeiten . Der 
Grundtakt kann z.B. aus einem internen Timer (Tl; FIG 10) 
kommen oder aus einem internen Takt (T3; FIG 10) eines Kommu- 
nikationsmediums (z.B. Profibus) oder aber der Takt kann auch 
aus einem Prozessereignis des technologischen Prozesses abge- 
leitet werden. Ein solches Prozessereignis kann z.B. die 
Taktrate (TG; FIG 10) eines Vorgangs an einer Produktionsma- 
schine oder Verpackungsmaschine sein. Anwenderebenen der Ebe- 
nengruppe "synchron getaktete Ebenen" konnen dabei basierend 
auf dem Grundtakt getaktet werden, sie konnen aber auch syn- 
chron zu einer der Systemebenen der Ebenengruppe "synchron 
getaktete Ebenen" laufen. Die Anwendertasks dieser zu einer 
Systemebene synchronen Anwenderebene haben somit eine syn- 
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chrone, d.h. deterministische Beziehung zu einer vom Anwender 
flexibel festlegbaren Systemebene . Das hat den Vorteil, dass 
deterministische Reaktionen auf Systemtasks ( Systemtasks lau- 
f en in den Systemebenen) , die der Anwender in seinen Anwen- 

5 dertasks programmiert hat, die in den Anwenderebenen der Ebe- 
nengruppe "synchron getaktete Ebenen" laufen, vom System ga- 
rantiert werden. Das heilit z.B., dass das System garantiert, 
dass diese "synchrone Anwenderebene" entsprechend beispiel- 
haft vor dem Interpolator aktiviert wird oder aber auch vor 

0 einer beliebigen anderen Systemf unktion . 

Die " zeitgesteuerte Anwenderebene", die "ereignisgesteuerte 
Anwenderebene", die "sequentielle Anwenderebene", die "zykli- 
sche Anwenderebene" sowie die "Anwenderebene fiir System Ex- 
5 ceptions" sind optional. 

Die Task der "zyklischen Anwenderebene" (Background Task) ist 
zykluszeituberwacht - Die "Motion Tasks" dagegen sind nicht 
zykluszeitiiberwacht und dienen im wesentlichen zur Beschrei- 

0 bung sequentieller Ablaufe. Das heiftt, das vorliegende Ab- 
lauf ebenenmodell unterstiitzt einen Anwender sowohl bei der 
Programmierung von sequentiellen Ablaufen als auch bei der 
Ereignisprogrammierung . Es konnen somit synchrone Ereignisse 
als auch asynchrone Ereignisse durch die Programmierung er- 

5 fasst werden. In die Anwenderebenen sind die vom Anwender er- 
stellten Anwenderprogramme (API - AP4; FIG 5) zuladbar. Die 
Anwenderprogramme API bis AP4 werden ublicherweise mit Hilfe 
einer Programmierumgebung des Engineering-Systems (ES; FIG 3) 
erstellt . 

0 

Die Darstellung gemafi FIG 5 zeigt ein Ausf Uhrungsbeispiel fiir 
das Zuladen von Anwenderprogramm in die Anwenderebenen. FIG 5 
zeigt exemplarisch eine Auspragung von Anwenderebenen des Ab- 
lauf ebenenmodells . Durch die drei Punkte am unteren Rand der 
5 Zeichnung ist dargestellt, dass auch noch weitere Anwender- 
ebenen, aber auch Systemebenen vorhanden sein konnen. Die 
Priorisierung der Ebenen wird wie im Vorangegangenen durch 
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einen Pfeil in Richtung zur hochsten Prioritat angedeutet. 
Den Anwenderebenen werden die Anwenderprogramme API bis AP4, 
am rechten Bildrand durch kleine Rechtecke angedeutet, zuge- 
ordnet. Die Zuordnung wird dargestellt durch Zuordnungspf eile 
ZP1 bis ZP4 , In den Anwenderebenen befinden sich Tasks, die 
die zugeladenen Anwenderprogramme API bis AP4 aufnehmen. Die- 
se Tasks werden dann nach einer gewissen Strategie (z.B. se- 
quentiell) durchlaufen bzw. abgearbeitet . Sie konnen weiter- 
hin die Eigenschaft besitzen, dass sie lauf zeituberwacht 
sind. 

Die Darstellung gemafi FIG 6 zeigt ein Ausf uhrungsbeispiel fur 
den Gebrauch und den Mechanismus des Wait_f or__Condition- 
Befehls, im Ablauf ebenenmodell der erf indungsgemaflen indus- 
triellen Steuerung. Der Wai t_f or_Condition-Bef ehl (in FIG 6 
dargestellt als wait_f or^cond ( ) ) wird in dieser Darstellung 
exemplarisch in der "sequentiellen Anwenderebene" verwendet. 
Der Wait_f or_Condition-Bef ehl wird in den vom Anwender er- 
stellten "Motion Tasks" MT1 und MT2 verwendet, die Bestand- 
teil der "sequentiellen Anwenderebene" sind. Die "Motion 
Tasks" MT1 und MT2 hangen in einem Round-Robin-Zyklus, darge- 
stellt durch den Pfeil von MT1 nach MT2 und durch den abge- 
winkelten Pfeil von MT2 zu MT1. Die drei Punkte innerhalb 
dieses Pfeiles deuten an, dass noch weitere "Motion Tasks" im 
Round-Robin-Zyklus hangen konnen. Die "Motion Task" MT1 ent- 
halt den Wait_f or_Condition-Bef ehl "wait_f or_cond (cond__l ) " , 
die "Motion Task" MT2 den Wait_f or-Condition-Bef ehl 
"wait_for_cond (cond_2) " . Jeweils drei Punkte, die innerhalb 
von MT1 bzw. MT2 verwendet werden, deuten an, dass neben den 
beiden Wait_f or_Condition-Bef ehlen und den drei Positionier- 
befehlen posl () bis pos3() noch weitere Befehle in den "Moti- 
on Tasks" enthalten sein konnen. 

Insgesamt besteht das in FIG 6 exemplarisch dargestellte Ab- 
lauf ebenenmodell eines Runtime-Systems fUr eine industrielle 
Steuerung aus folgenden Ebenen (aufgezahlt von niedrigster 
bis hochster Prioritat) : "zyklische Anwenderebene", "sequen- 
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tielle Anwenderebene" (die Tasks dieser beiden Ebenen haben 
die gleiche Prioritat, dargestellt durch die gestrichelte Li- 
nie zwischen diesen Ebenen), " zeitgesteuerte Anwenderebene" , 
"ereignisgesteuerte Anwenderebene", "Anwenderebene fur Syste- 
mexceptions", "synchron getaktete Anwenderebene 2", "syn- 
chron getaktete Anwenderebene 1", "synchron getaktete System- 
ebene 2" und als hochstpriore Ebene eine "synchron getaktete 
Systemebene 1". 

Die Arbeitsweise des Wait_f or_Condition-Bef ehls wird bei- 
spielhaft an "wait_f or_cond (cond_l ) " aus der "Motion Task" 
MT1 gezeigt. 1st die "Motion Task" MT1 im Round-Robin-Zyklus 
an der Reihe, werden die Befehle der "Motion Task" MT1 solan- 
ge bedient, bis die Zeitscheibe abgelaufen ist, oder eine Un- 
terbrechung kommt . Trifft dies zu, wird die "Motion Task" MT2 
als nachste Task im Zyklus bedient, usw. Wird in der "Motion 
Task" MT1 der wait_f or_cond (cond_l ) -Bef ehl abgearbeitet , wird 
die Bedingung cond_l uberpruft. Ist cond__i = true, also er- 
fullt, dann wird sofort der nachst f olgende Bef ehl pos2() aus- 
gefiihrt und eventuell weitere in MT1 vorhandene Befehle suk- 
zessive abgearbeitet, bis die Kontrolle an die nachste Task 
abgegeben wird. 

Ist die Bedingung cond_l = false, also nicht erfullt, wird 
sofort die "Motion Task" MT1 unterbrochen und im Round-Robin- 
Zyklus wird MT2 bedient. Die Bedingung cond_l wird aber in 
die "synchron getaktete Systemebene 2" eingehangt (angedeutet 
durch den durchgehenden abgewinkelten Pfeil vom 
wait_for_cond (cond_l ) -Bef ehl zu der "synchron getakteten Sys- 
temebene 2") und im Takt dieser Systemebene auf ihr Erfullt- 
sein uberpruft. Ist die Bedingung cond_l erfullt, wird im 
Round-Robin-Zyklus die aktuelle Task verdrangt, d.h. ihr wird 
die Zeitscheibe entzogen und die Motion Task MT1 wird sofort 
unmittelbar nach dem wait_f or_cond (cond_l ) mit dem Positio- 
nierbefehl pos2() fortgesetzt. Durch den gestrichelten Pfeil 
wird der Rucksprung aus der "synchron getakteten Systemebene 
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2" zum Positionierbef ehl pos2(), d.h. zur "sequentiellen An- 
wenderebene" angedeutet . 

Dadurch, dass bei Nichter f ulltsein der Bedingung des 
Wait_f or_Condition-Bef ehls die Oberpriifung der Bedingung in 
einer hochprioren "synchron getakteten Systemebene" stattfin- 
det, und bei Erfiilltsein der Bedingung sofort die unterbro- 
chene "Motion Task" fortgesetzt wird, ist es einem Anwender 
moglich, bei der Programmierung von Bewegungssequenzen extrem 
zeitkritische Applikationen mit einfachen Sprachmitteln zu 
spezif izieren . Die Performance und Deterministik wird noch 
dadurch erhoht, dass beim Oberprufen der Bedingungen in den 
jeweiligen hochprioren "synchron getakteten Systemebenen" nur 
aktuell anstehende Bedingungen eingehangt und berucksichtigt 
werden . 

Der hier beschriebene Mechanismus erfordert auch keinen ex- 
pliziten Event-Handier. Der grofie Vorteil aus Anwendersicht 
liegt somit darin, dass der Anwender jetzt in einem sequen- 
tiellen Ablaufprogramm auf einer relativ niedrigen Priori- 
tatsebene einer "Motion Task" in seinem Programmf luss 
hochpriore Ereignisse mit Hilfe von Programmkonstrukten for- 
mulieren kann und nicht in ein anderes Programm wechseln 
muss, das er dann Uber andere Mechanismen (z.B. per Hand oder 
interruptgesteuert ) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 
gramm geschlossen zu formulieren. 

Die Bedingungen, die in einem Wait_f or_Condition-Bef ehl abge- 
fragt werden, konnen vom Anwender sehr flexibel und elegant 
formuliert werden. So kann der Anwender zur Formulierung die- 
ser Bedingungen Programmvariablen aus einem Anwenderprogramm 
verwenden oder interne Groiien der Steuerung oder er kann auch 
Prozesssignale ref erenzieren . Diese Groiien konnen dann lo- 
gisch, arithmetisch oder mit beliebigen Funktionen inhaltlich 



verknupft werden, urn daraus eine Bedingung zu formulieren. 
Neben dem hochprioren Abfragen, ob die Bedingung erfullt ist, 
kann man sich auch vorstellen, dass bei Erfulltsein der Be- 
dingung auch noch dazugehoriger Programmcode, d.h. eine da- 
hinterliegende Reaktion, die anwenderprogrammierbar ist, 
hochprior ausgefiihrt wird. Und dass erst nach der Ausflihrung 
dieses Prograituncodes der Rucksprung in die niederpriore Ebene 
erf olgt . 

Die Darstellung gemafi FIG 7 zeigt ein erweitertes Ausfiih- 
rungsbeispiel fur den Gebrauch und den Mechanismus des 
Wait_for_Condition-Befehls, im Ablauf ebenenmodell der erfin- 
dungsgemaflen industriellen Steuerung. Der Wai t_f or_Condition- 
Befehl (in FIG 7 ebenfalls dargestellt als wait__f or_cond ( ) ) 
wird in dieser Darstellung exemplarisch in der "sequentiellen 
Anwenderebene" verwendet . Der Wait_f or_Condition-Bef ehl wird 
in den vom Anwender erstellten "Motion Tasks" MT3 und MT4 
verwendet, die Bestandteil der " sequent ielien Anwenderebene" 
sind. Die "Motion Tasks" MT3 und MT4 hangen in einem Round- 
Robin-Zyklus, dargestellt durch den Pfeil von MT3 nach MT4 
und durch den abgewinkelten Pfeil von MT4 zu MT3. Die drei 
Punkte innerhalb dieses Pfeiles deuten an, dass noch weitere 
"Motion Tasks" im Round-Robin-Zyklus hangen konnen. Die "Mo- 
tion Task" MT3 enthalt den Wait_f or_Condition-Bef ehl 
"wait_for_cond(cond_3) ", die "Motion Task" MT4 den Wait_for- 
Condition-Bef ehl "wait_f or_cond (cond_4 ) " . Jeweils drei Punk- 
te, die innerhalb von MT3 bzw. MT4 verwendet werden, deuten 
an, dass neben den beiden Wait_f or_Condition-Bef ehlen und den 
Positionierbefehlen pos4() bis pos8() noch weitere Befehle in 
den "Motion Tasks" enthalten sein konnen. Durch die program- 
miersprachlichen Konstrukte "wait_f or_cond ( ) " und 
"end_wait_for_cond" wird eine Programmsequenz in den "Motion 
Tasks" geklammert. In der "Motion Task" MT3 sind die Befehle 
pos5() und pos6() auf diese Weise geklammert. Auch in der 
"Motion Task" MT4 wird die Verwendung von "wait__f or^cond ( ) " 
und "end_wait_for_cond" angedeutet. Durch jeweils 3 Punkte 
ist in der "Motion Task" MT4 skizziert, dass vor, innerhalb 
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und nach dem "wait_f or_cond ( ) - end_wait_f or_cond"-Konstrukt 
weitere Anweisungen vorhanden sein konnen. 

Das in FIG 7 exemplarisch dargestellte Ablauf ebenenmodell ei- 
nes Runtime-Systems fur eine industrielle Steuerung besteht 
wie .in FIG 6 aus folgenden Ebenen (aufgezahlt von niedrigster 
bis hochster Prioritat) : "zyklische Hintergrundebene" , "se- 
quentielle Anwenderebene" (die Tasks dieser beiden Ebenen ha- 
ben die gleiche Prioritat, dargestellt durch die gestrichelte 
Linie zwischen diesen Ebenen) , "ereignisgesteuerte Anwender- 
ebene", " zeitgesteuerte Anwenderebene", "Anwenderebene fiir 
Systemexceptions", "synchron getaktete Anwenderebene 2", 
"synchron getaktete Anwenderebene 1", "synchron getaktete 
Systemebene 2" und als hochstpriore Ebene eine "synchron ge- 
taktete Systemebene 1". 

In FIG 7 wird die Arbeitsweise des Wait_f or_Condition-Bef ehls 
mit einer dazugehorigen Programmsequenz gezeigt beispielhaft 
an "wait_f or_cond (cond_3) " aus der "Motion Task" MT3 gezeigt". 
Das Uberpriifen der Bedingung cond__3 und das Abarbeiten der 
dazugehorigen Programmsequenz (geklammert zwischen 
"wait_f or_cond (cond_3) " und " end_wait_f or_cond" ) erfolgen da- 
bei auf einer hoherprioren Ebene des Ablauf ebenenmodells . Die 
zu "wait_for_cond (cond_3) " dazugehorigen Programmsequenz wird 
durch die Abfolge der Befehle pos5() und pos6() gebildet. 

1st die "Motion Task" MT3 im Round-Robin-Zyklus an der Reihe, 
werden die Befehle der "Motion Task" MT3 solange bedient, bis 
die Zeitscheibe abgelaufen ist, oder eine Unterbrechung 
kommt. Trifft dies zu, wird die "Motion Task" MT4 als nachste 
Task im Zyklus bedient, usw. Wird in der "Motion Task" MT3 
der "wait_for_cond (cond_3) "-Befehl abgearbeitet, so wird die 
Bedingung cond_3 uberpruft. Ist cond_3 = true, also erfUllt, 
dann wird der normale Programmablauf fortgesetzt, d.h. als 
nachstes wird der Befehl pos5() ausgefiihrt und eventuell wei- 
tere in MT3 vorhandene Befehle sukzessive abgearbeitet, bis 
die Kontrolle an die nachste Motion Task abgegeben wird. 
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1st die Bedingung cond_3 = false, also nicht erftillt, wird 
sofort die "Motion Task" MT3 unterbrochen und im Round-Robin- 
Zyklus wird MT4 bedient. Die Bedingung cond_3 und die Befehle 
pos5() und pos6() (als dazugehorige Programmsequenz ) werden 
5 in der Prioritat der "synchron getakteten Systemebene 2" be- 
arbeitet (angedeutet durch den durchgehenden abgewinkelten 
Pfeil, ausgehend von der Klammer, die die Zusammengehorigkeit 
von wait_f or_cond (cond_3 ) , end_wait'^for_cond und dazugehori- 
ger Programmsequenz ausdriickt, hin zu der "synchron getakte- 
10 ten Systemebene 2") . Im Takt dieser Systemebene wird cond_3 
auf ihr Erfulltsein uberpriift. 1st die Bedingung cond_3 er- 
fullt, wird mit der Prioritat der "synchron getakteten Sys- 
temebene 2" die dazugehorige Programmsequenz (hier: die Ab- 
folge der Befehle pos5() und pos6() abgearbeitet . Durch den 
15 gestrichelten Pfeil wird der Riicksprung aus der "synchron ge- 
takteten Systemebene 2" zum Positionierbef ehl pos7(), d.h. 
zur "sequentiellen Anwenderebene" angedeutet. 

Dadurch, dass bei Nichter f tilltsein der Bedingung des : 
20 Wait_for_Condition-Bef ehls die Uberpruf ung der Bedingung in 

einer hochprioren "synchron getakteten Systemebene" stattfin- 
det, und bei Erfulltsein der Bedingung sofort eine dazugeho- 
rige, vom Anwender erstellbare Programmsequenz auf dieser 
hochprioren Systemebene ausgeftihrt wird, konnen sogar extrem 
zeitkritische Applikationen mit einfachen Sprachmitteln spe- 
m^m zifiziert und durchgefiihrt werden. 

Ein moglicher Anwendungsf all ist die Druckmarkensynchronisa- 
tion. Dabei geht es darum, eine Druckmarke auf einem Material 

30 hochprior zu erkennen. Beim Erkennen dieser Druckmarke wird 
typischerweise ein Istwert erfasst ("Latchen" z.B. eines La- 
ge- oder Geberistwertes ) . Ausgehend von diesem erfassten Ist- 
wert wird ein Korrekturwert berechnet, der dem System als u- 
berlagerte Bewegung aufgepragt wird. Der Vorgang Istwert- 

35 Erkennung, Korrekturwert-Berechnung und Durchfuhrung der u- 

berlagerten Bewegung muss in einer deterministischen Zeitdau- 
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er erfolgen. Deswegen muss dieser Vorgang hochprior stattfin- 
den . 

Ein weiterer Anwendungsf all 1st der "schnelle Bewegimgs- 
start". Hier geht es darum, z.B. Flankenwechsel sehr schnell 
zu erkennen und daran sofort anschliefiend einen Bewegungs- 
start (z.B. Positionierbewegung) zu beginnen. Die Determinis- 
tik Erkennen eines Ereignisses und Auslosen von Folgeaktionen 
ist entscheidend fur die Produktivitat einer Maschine. Bei 
Produktionsmaschinen mussen solche zyklischen Vorgange in ei- 
ner deterministischen Zeit, z.B. <100 ms oder <50 ms erfol- 
gen. Beim Abarbeiten der Tasks auf einer normalen Hinter- 
grundebene kann diese Deterministik nicht garantiert werden. 
Der beschriebene Mechanismus ist besonders fiir einen Einsatz 
bei Maschinen geeignet, die periodische Maschinenzyklen auf- 
weisen. 

Die Performance wird noeh dadu-rch erhoh-t, dass beim Oberpru- 
f en der Bedingungen in den j eweiligen hochprior en "synchron 
getakteten Systemebenen" nur aktuell anstehende Bedingungen 
eingehangt und berucksichtigt werden. 

Der hier beschriebene Mechanismus erfordert, wie schon in FIG 
6 erwahnt, keinen expliziten Event-Handler. Der groUe Vorteil 
aus Anwendersicht liegt somit darin, dass der Anwender jetzt 
in einem sequentiellen Ablauf programm auf einer relativ nied- 
rigen Prioritatsebene einer "Motion Task" in seinem Programm- 
fluss hochpriore Ereignisse mit Hilfe von Programmkonstrukten 
formulieren kann und nicht in ein anderes Programm wechseln 
muss, das er dann uber andere Mechanismen (z.B, per Hand oder 
interruptgesteuert) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 
gramm geschlossen zu formulieren. 
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Der Wait_f or_Condition-Bef ehl kann vom Anwender sehr flexibel 
und einfach eingesetzt werden, da er als normales program- 
miersprachliches Konstrukt zur Verfugung steht. Auch die For- 
mulierung der Bedingungen ist fur einen Anwender flexibel und 
5 einfach. So kann der Anwender zur Formulierung dieser Bedin- 
gungen Programmvariablen aus einem Anwenderprogramm verwenden 
oder interne Grofien der Steuerung oder er kann auch Prozess- 
signale ref erenzieren . Diese Grolien konnen dann logisch, a- 
rithmetisch oder mit beliebigen Funktionen inhaltlich ver- 
10 kntipft werden, um daraus eine Bedingung zu formulieren. 

Durch das Wait_f or_Condition-Konstrukt hat ein Anwender die 
Moglichkeit in normalen Anwenderprogrammen fur Bewegungsse- 
quenzen, ein Anwenderprogramm temporar auf eine hohere Prio- 
15 ritatsebene zu legen, um deterministische Vorgange garantie- 
ren zu konnen. 

Darstellung gemafi FIG 8 zeigt das programirtiersprachiiche Kon- 
strukt des wait_f or_condition-Mechanismus als Syntaxdiagramm. 
20 Die terminalen Elemente sind dabei mit abgerundeten Ecken 
dargestellt : "WAITFORCONDITION" , "WITH", "DO", 

" END_WAI T FORCOND I T I ON " und ";". Als Rechtecke sind die nicht- 
terminalen Elemente. dargestellt: "Expressions-Bezeichnung, 
"SCHALTER" und "ANWEISUNGSTEIL" ♦ Die Elemente "WITH" und 
| 25 "SCHALTER" sind optional. 

Darstellung gemafi FIG 9 zeigt die Verwendung des 
Wait_f or_Condition-Konstruktes in einem Programmablauf . Im 
oberen Teil von FIG 9 ist die Formulierung der Bedingung "my- 
30 Expression" dargestellt, im unteren Teil ist gargestellt, wie 
diese Bedingung in einem Wait_f or_Condition-Konstrukt verwen- 
det wird. 

Darstellung gemafi FIG 10 zeigt in einer Schemadarstellung 
35 Moglichkeiten, wie der Grundtakt fiir die industrielle Steue- 
rung gewonnen wird. FIG 10 zeigt exemplarisch eine Kommunika- 
tionstopologie, in die die Steuerung S integriert ist. Die 
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Steuerung S ist durch ein Rechteck dargestellt . Durch eine 
Anschlussleitung A2 ist die Steuerung S mit dem Bus Bl ver- 
bunden, an dem uber eine Anschlussleitung Al das externe Ge- 
rat EG hangt. Uber den Bus B2 erfolgt die Verbindung zum 
technischen Prozess P2 . Der technische Prozess P2 ist am un- 
teren Bildrand durch ein Rechteck dargestellt. Uber die An- 
schlussleitung A3 ist die Steuerung S mit dem Bus B2 verbun- 
den, der wiederum uber die Anschlussleitung A4 die Verbindung 
zum technischen Prozess P2 herstellt. 

Die Generierung fur den Grundtakt der Steuerung S kann aus 
unterschiedlichen Taktquellen erfolgen. So z.B. aus einer in- 
ternen Taktquelle, dargestellt durch den internen Timer T2 
der Steuerung S oder auch durch eine externe Taktquelle wie 
z.B. den Timer Tl, der zum externen Gerat EG gehort. Als ex- 
terne Taktquelle kann aber auch der Grundtakt eines Kommuni- 
kationsmediums dienen. Wenn der Bus B2 z.B. durch einen aqui- 
distanten Profibus realisiert wird, dann kann der Takt fur 
die Steuerung aus dem Grundtakt dieses Busses gewonnen wer- 
den. In FIG 10 ist dies dargestellt dadurch, dass der Timer 
T3 direkt an der Anschlussleitung A3 positioniert ist, und 
diese Anschlussleitung A3 stellt die Verbindung zum Bus B2 
her. Die Steuerung hangt somit als Slave am Bus und kann di- 
rekt den Bustakt verwenden. Weiterhin kann als externe Takt- 
quelle ein Taktgeber TG dienen, der im technischen Prozess P2 
integriert ist. Ein Taktgeber TG in einem technischen Prozess 
kann z.B. der Arbeitstakt einer Produktionsmaschine oder Ver- 
packungsmaschine sein. In der Darstellung gemalb FIG 10 sind 
als Kommunikationsmedien beispielshaf t Busverbindungen darge- 
stellt. Es konnen aber als Kommunikationsmedien aber auch 
Ring-, Stern- oder andere Verbindungsarten gewahlt werden, 
auch wireless-Verbindungen . Aus diesen Verbindungssystemen 
kann dann der oben genannte Grundtakt abgeleitet werden. 
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Patentanspruche 

1. Verfahren zur Programmierung von zyklischen Maschinen, 
insbesondere von Produktionsmaschinen, 

gekennzeichnet durch folgende aufeinan- 
der folgenden Schritte: 

d) Erstellen einer mit einem Runtime-System (RTS) ausgestat- 
teten industriellen Steuerung (S) mit priorisierten Ab- 
laufebenen und Tasks, wobei mindestens eine sequentielle 
Ablaufebene erstellt wird, 

e) Formulieren eines Maschinenablauf s in einem sequentiellen 
Programm und 

f) im sequentiellen Programm durch spezifische Mechanismen 
bereitstellen, dass 

1) das Warten auf das Erfuiitsein von Bedingungen 
hochprior durchgefuhrt werden kann und 

2) dass nach Erfuiitsein der Bedingung die nachfolgen- 
de Programmsequenz bis zu einem definierten anwen- 
derprogrammierten Ende hochprior durchgefuhrt wer- 
den kann, 

wobei den Ablaufebenen System- und/oder Anwenderprogramme 
(API - AP4) zugeordnet werden, 

2. Verfahren zur Programmierung nach Anspruch 1, 
dadurch gekennzeichnet, 

dafl die Ablaufebenen aus Systemebenen und/oder Anwenderebenen 
erstellt werden, 

3. Verfahren zur Programmierung nach Anspruch 1 oder 2, 
dadurch gekennzeichnet, 

dass das Ablauf ebenenmodell getaktet ist, wobei der Grundtakt 
aus einem internen Timer (T2) oder aus einem internen Takt 
(T3) eines Kommunikationsmediums (Bl, B2) oder aus einem ex- 
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ternen Gerat (EG) Oder von einer Grofie (TG) , die zum techno- 
logischen Prozess (PI, P2) gehort ableitbar ist. 
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Zusammenf as sung 

Programmierung von zyklischen Maschinen 

In einfacher Weise wird ein konf igurierbares Ablauf ebenenmo- 
dell eines Runtime-Systems (RTS) fur die S teuerungs-Tasks ei 
ner industriellen Steuerung (S) fur zyklische Maschinen er- 
stellt, wobei die Programmierung des Maschinenablauf s in ei- 
nem sequentiellen Programm erfolgen kann. Der 

Wait_for_Condition-Bef ehl ermoglicht es dabei einem Anwender 
im Programmf luss auf beliebige Bedingungen zu warten und ho- 
herprior zu reagieren. Den Anwenderebenen des Ablauf ebenenmo 
dells konnen Anwenderprogramme (API - AP4) zugeladen werden. 



FIG 6 
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Synchron getaktete Ebenen 



Anwenderebene fur Systemexceptions 
ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 
sequentielle Anwenderebene 
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synchron getaktete Anwenderebene 3 
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ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 
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END WAITFORCONDITION 



FIG 8 



IMPLEMENTATION 
EXPRESSION myExpression 

//Vereinbarung lokaler Variablen moglich 
VAR 

myLoc : WORD 
END_VAR 

myLoc :=%IW10 & 16#ff00; 

//Dies ist eine mit WAITFORCONDITION auszuwertende 
//Bedingung (Ruckgabewert der Funktion) . Wenn FALSE, 
//wird die betreffende Task ausgesetzt, bis Bedingung 
//TRUE ergibt. 

myExpression : =myloc <> 16#0100; 
END EXPRESSION 



PROGRAM myProgram 

//Aufruf des Befehls mit Namen der Expression 
WAITFORCONDITION myExpression WITH TRUE DO 

// hier mind, eine Anweisung, wird hochprior ausgefiihrt 
END_WAI TFORCOND I T ION ; 

END_PROGRAM 
END IMPLEMENTATION 
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